Soundtouch offset compensation updated #11154
Conversation
|
I haven't checked, but does soundtouch not report this information? Just like we can query librubberband for how much padding it requires and what the effective latency is for the current time ratio setting. |
|
For my undestanding the situation in 2.1.1 was a shortcoming, improved in 2.3.0. I am not aware of a reporting measure. Unlike in rubberband, this is an offset on the input, not a padding against a ramp up. The ramp is still there. It is even worse, because the frst processed chunk has a different offset. |
|
@robbert-vdh do you have interest to review and check this? (This PR is collecting dusk :-/) |
|
Before I do the same thing and reach the same (lack of) conclusion, did you already check the SoundTouch documentation for a way to get this offset programmatically? Surely there must be a way to get this information without having to measure it. If measuring really is the only way to go, I'd propose implementing a small routine that on startup/first load just runs an impulse through the SoundTouch time stretcher and measures the delay based on that. Then there's no need to hardcode values into Mixxx that may depend on the exact SoundTouch version. |
|
There is no way to get timing information out of SoundTouch: The issue is that the offset was actually bug it SoundTouch < 2.3.0 which has now been fixed. |
|
@robbert-vdh can you have a second look here? |
| // From V 2.3.0 Soundtouch has no initial offset at unity, but it is to early with | ||
| // lowered pitch and to early with raised pitch ~+-2000 farmes = 50 ms. |
There was a problem hiding this comment.
I don't understand the comment. also typos
| // From V 2.3.0 Soundtouch has no initial offset at unity, but it is to early with | |
| // lowered pitch and to early with raised pitch ~+-2000 farmes = 50 ms. | |
| // From V 2.3.0 Soundtouch has no initial offset at unity, but it is too early with | |
| // lowered pitch and too early with raised pitch ~+-2000 frames = 50 ms. |
There was a problem hiding this comment.
Can you elaborate on this, does the 2000ms just mean latency? how are you estimating time from that?
There was a problem hiding this comment.
I have added the description of my test.
Does it help?
There was a problem hiding this comment.
I appreciate the comment, but it didn't really help. I have a couple questions:
- what exactly do you mean with offset in this comment? Latency expressed as a number of frames/samples?
- how can that offset be earlier (lowered/raised pitch) than no offset (at unity (which I assume means no change in pitch)).
There was a problem hiding this comment.
1 In my test with extrem pitches, the saw tooth was shifted by up to 2000 frames compared to the unity signal. This is relative to the pitch, but I have not investigated how exactly.
2 It can be earlier, because of the settling samples. Soundtouch needs some samples to be settled before you can consume the output even at unity. Mixxx controls the output and recent Soundtouch compensates the input correct only at unity.
|
Do we need backwards compatibility for old SoundTouch versions? We could try to detect the version with cmake and define some preprocessor variable. But I have no idea if anyone still uses older versions of SoundTouch. |
Co-authored-by: Swiftb0y <12380386+Swiftb0y@users.noreply.github.com>
daschuer
force-pushed
the
soundtouchoffset
branch
from
883f991 to
2993cd2
Compare
|
Our lowest supported version is 2.1.2 form Ubuntu Focal. The runtime check is required, because one may update the SoundTouch version without recompiling Mixxx. |
|
Ok. |
daschuer
force-pushed
the
soundtouchoffset
branch
from
eadc013 to
dc60346
Compare
|
OK, done after resolving a distance conflict. |
Co-authored-by: Swiftb0y <12380386+Swiftb0y@users.noreply.github.com>
Replace the outdated offset compensation for soundtouch 1.8 by a comensation for version 2.1.1 to 2.3
Consider the latency before adopting new rate or pitch when calculating the playposition.